Date: Mon, 15 Feb 93 04:30:04 PST
From: Packet-Radio Mailing List and Newsgroup <packet-radio@ucsd.edu>
Errors-To: Packet-Radio-Errors@UCSD.Edu
Reply-To: Packet-Radio@UCSD.Edu
Precedence: Bulk
Subject: Packet-Radio Digest V93 #41
To: packet-radio


Packet-Radio Digest         Mon, 15 Feb 93       Volume 93 : Issue   41

Today's Topics:
              MOCOM 70 modification experience (2 msgs)
              msg traffic for kd7hp@mso plus a question
                   Newsreader for NOS NNTP server?
                       Packet-Radio Digest V93
               Packet Modem Prices and Speeds? (2 msgs)
                         Palmtops and packet?
                     Posting to NOS NNTP (2 msgs)
                      Welcome to rec.radio.info!
                    Yaesu FT-990 & PK232MBX Users?

Send Replies or notes for publication to: <Packet-Radio@UCSD.Edu>
Send subscription requests to: <Packet-Radio-REQUEST@UCSD.Edu>
Problems you can't solve otherwise to brian@ucsd.edu.

Archives of past issues of the Packet-Radio Digest are available 
(by FTP only) from UCSD.Edu in directory "mailarchives/packet-radio".

We trust that readers are intelligent enough to realize that all text
herein consists of personal comments and does not represent the official
policies or positions of any party.  Your mileage may vary.  So there.
----------------------------------------------------------------------

Date: 14 Feb 93 23:39:29 CST
From: tulane!agwbbs!Angelo_Glorioso_Iii@ames.arpa
Subject: MOCOM 70 modification experience
To: packet-radio@ucsd.edu

Hi Dave,

 We have several of them in use here in New Orleans and thourgh out the
Gulf coast.. We are using 446.100 thought.. This is about as low as they
can go..

73, Angelo


-- Via DLG Pro v0.995

Internet:angelo_glorioso_III@agwbbs.new-orleans.LA.US
  Usenet:rex!agwbbs!angelo_glorioso_III
  Packet:N5UXT @ N5UXT.#NOLA.LA.USA.NA
  Tcp/ip:N5UXT.AMPT.ORG  [44.108.2.13]

------------------------------

Date: 14 Feb 93 23:35:56 CST
From: tulane!agwbbs!Angelo_Glorioso_Iii@ames.arpa
Subject: MOCOM 70 modification experience
To: packet-radio@ucsd.edu

Hi Bob,

 We have several of the Mocom 70 UHF radios running at 9600 Bps here in the

Gulf coast area.. They work good. If you leave me your address, I will be
glad to mail you a copy of the mod..

73,Angelo

-- Via DLG Pro v0.995

Internet:angelo_glorioso_III@agwbbs.new-orleans.LA.US
  Usenet:rex!agwbbs!angelo_glorioso_III
  Packet:N5UXT @ N5UXT.#NOLA.LA.USA.NA
  Tcp/ip:N5UXT.AMPT.ORG  [44.108.2.13]

------------------------------

Date: Mon, 15 Feb 1993 06:20:34 GMT
From: usc!zaphod.mps.ohio-state.edu!saimiri.primate.wisc.edu!usenet.coe.montana.edu!selway.umt.edu!petey@network.UCSD.EDU
Subject: msg traffic for kd7hp@mso plus a question
To: packet-radio@ucsd.edu

Hello all. I am a tech. (n7xla) in Missoula mt.  I have not
gotten on Missoula Packet yet.  Is there a packet gateway to the Internet?

This way I can send E-mail to my friend, kd7hp who has a packet BBs in 
Missoula.  I have heard of a gate in Penn. however being that I just got 
on I saw no FAQ post.   If there is no formal gate, would someone
handle my msg   traffic? Please e-mail me @petey@selway.umt.edu

thanks

------------------------------

Date: Sat, 13 Feb 1993 17:31:30 GMT
From: sdd.hp.com!cs.utexas.edu!torn!watserv2.uwaterloo.ca!watserv1!ritchie.uwaterloo.ca!owpurbo@network.UCSD.EDU
Subject: Newsreader for NOS NNTP server?
To: packet-radio@ucsd.edu

I have been using fsuu12r4.zip as newsreader
for my NOS NNTP server for quite awhile.
It works fine for reading the news (in fact,
it is quite similar to Rn in UNIX).

Unfortunately, to follow-up, reply and post an article
it doesn't modify the /spool/news/history +
some other incompatibilities in the directories.
Well, actually it works - but I have to manually
edit the /spool/news/history by hand :-( ....

Would appreciate any info on a decent newsreader
fully compatible with NOS NNTP server
(hopefully with source code :-) .....

Thank you.

73 Onno YC1DAV/VE3 -sk-
        yc1dav@ve3.yc1dav.ampr.org [44.135.84.22]

------------------------------

Date: 15 Feb 93 03:10:39 GMT
From: news-mail-gateway@ucsd.edu
Subject: Packet-Radio Digest V93
To: packet-radio@ucsd.edu

        Reply to:   RE>Packet-Radio Digest V93 #39
Having seen the blurb about NosIntro and NosView I thought I would add my two
penn'orth.   

Some while ago I arranged with Ian to distribute NosView over the Internet (as
he does not have accesss) and it was made available on ucsd.edu and on tomcat. 
As far as I'm aware it is still there on those machines.  However I have not
received an update for some time and it is likely that a more recent version
exists.  Having just received a leaflet advertising NosIntro (first I've heard
of it) I have replied ordering a copy and also reminding Ian to send me NosView
for uploading onto the Internet.

If a new copy arrives I will upload it and post details here.

Nigel Watkinson   

ax25:  G0NGL@GB7NWP.#16.GBR.EU
internet:  nigel@sna.co.umist.ac.uk
fax  +44-61-200-3324
cix:  nigelw

------------------------------

Date: Sun, 14 Feb 1993 14:06:45 GMT
From: usc!wupost!emory!wa4mei!ke4zv!gary@network.UCSD.EDU
Subject: Packet Modem Prices and Speeds?
To: packet-radio@ucsd.edu

In article <1993Feb13.225757.18658@fcom.cc.utah.edu> val@fcom.cc.utah.edu (Val Kartchner) writes:
>I'm just starting to study for my license.  (The local club just started a
>class.)  I was wondering about the price of packet modems and which speeds
>I should look into getting?
>
>As an example of the type of reply that I'm looking for, here's an example
>for (telephone) modems:
>
>   Almost all modems will automatically connect at the highest common speed.
>   300 and 1200 bps modems are effectively obsolete.  2400 bps is the lowest
>   speed that you should even consider getting, but many BBS's still have
>   only this speed.  9600 bps (v.32) is common for new purchases, but for
>   a little bit ($50-$100) more, you can have 14400 bps (v.32bis).  The
>   28800 bps (nicknames v.fast/v.last) is comming out "real soon now", but
>   since many computers can't keep up, it may be better to stay with v.32bis.

Packet doesn't work this way, at least not completely. There's no call
setup negotiation in the packet world. Packet can be sent two different
ways, Virtual Circuit and Datagram. It's theoretically possible to negotiate
a VC connection speed, but with multi-connects or datagrams the modem has
to be able to decode every packet it hears. That makes negotiated speeds
a problem. Normally different speeds are used on different frequencies
and operators set them manually to match the other stations on the channel.

The two basic speeds are 300 and 1200 baud, both based on the half duplex 
Bell 202 standard tones. 300 baud is used on HF and 1200 is used on VHF 
due to regulatory issues and practical multipath issues at HF. Kantronics
introduced their 2400 baud modulation scheme some time ago and other
manufacturers have followed it so that all 2400 baud modems will talk
to each other. Some TNCs have dual modems and will respond to either
Bell 202 1200 baud or to 2400 baud Kantronics format packets. Origination
speeds have to be selected manually. 

Above 2400 we have the K9NG inspired 9600 baud modem. The most common 
implementation is the one by G3RUH. Again there are TNCs that can support 
this modem as a secondary modem and select downwards to Bell 202, but they 
aren't common. Also, at this speed most voice grade radios need modifications 
to work properly.

As we go to the higher speeds, we must discard the voice grade radio
approach. At 19.2 kilobaud, most users are directly FSKing special
purpose radios such as the Kantronics D4, though some are using the
Kantronics 19.2 kb modem which includes a scrambler to prevent bit
bias. When you go to the GRAPES 56 kilobaud modem, the modem *becomes*
the radio. This unit uses a modulation scheme called MSK for Minimum
Shift Keying. It includes a scrambler and a tracking data detector
that will handle off frequency and drifting signals at UHF. That's as 
fast as available equipment supports today.

There are faster systems in use experimentally. The GRAPES modem
can be speed doubled to 112 kb, and there are experimental 100 kb to
1 megabaud microwave radios in operation on the West Coast. Finally, 
a few hams have experimented with ethernet over microwave at 10 GHz. 
This gives a potential data rate of 10 megabits per second.

>As a packet protocol, EC (error correction) is inherent in the protocol,
>correct?  Would a TNC with builtin DC (data compression) (effectively) be
>ruled out because of the FCC restriction on "clear text" transmission?  Or,
>would it be ruled out because of the need of the remote modem to maintain
>an updated compression table which isn't feasible?

The packet protocol in use at the link level, AX25V2, does not support
error correction. It does support error detection. When used in VC mode,
it operates as an ARQ protocol with the receiving station sending ACKS or
acknowledgement packets for correctly received frames. The transmitting
station will resend any packets for which it doesn't receive an ACK within
a specified timeout interval. In essence this is similar to the venerable
XMODEM protocol used for file transfer by landline systems. When used in
datagram mode, AX25V2 does not do ACKs and so is not an ARQ protocol.
That function moves to a higher level in the protocol stack, such as
the TCP level of the TCP/IP protocol suite that is often used by amateurs
on top of the AX25V2 link layer.

New schemes, called Pactor and Clover are in use at HF that do include
elements of FEC, Forward Error Correction, allowing the receiving station
to reconstruct damaged frames. At VHF and UHF the channel error rate is
usually low enough not to warrant the overhead of FEC schemes. Either the
frame gets through undamaged, or it's so totally clobbered by a collision
that FEC doesn't help.

Data compression, either on the fly or compressed file transmission,
is perfectly legal on the amateur bands *if* the compression is meant
to facilitate communications and is not intended to obscure meaning.
This is not considered encryption under the rules, IE it is still "plain
text" assuming you have the proper decompression software. Encryption is
generally illegal except for certain telecommand functions. Any published 
scheme that can be reproduced by any other similarly equipped amateur is 
perfectly acceptable. Even systems that are not in wide public use are 
acceptable if station records are kept of the compression algorithm to 
allow the FCC to decompress any transmissions they may have intercepted. 
Systems that require confidential private keys are *not* acceptable.

I haven't heard of anyone using on the fly compression, and don't know
of any commercial implementations for TNCs, but compressed binary file
transmissions using schemes like PKzip are routine. I think I've heard
of some forwarding BBS systems using message compression, but I don't
know if it's done on the fly or in advance of transmission.

I hope this summary is useful.

Gary
-- 
Gary Coffman KE4ZV          |    You make it,     | gatech!wa4mei!ke4zv!gary
Destructive Testing Systems |    we break it.     | uunet!rsiatl!ke4zv!gary
534 Shannon Way             |    Guaranteed!      | emory!kd4nc!ke4zv!gary 
Lawrenceville, GA 30244     |                     | 

------------------------------

Date: 15 Feb 1993 03:18:23 -0500
From: usc!hela.iti.org!cs.widener.edu!widener!nobody@network.UCSD.EDU
Subject: Packet Modem Prices and Speeds?
To: packet-radio@ucsd.edu

In article <1993Feb13.225757.18658@fcom.cc.utah.edu> val@fcom.cc.utah.edu (Val Kartchner) writes:
>
>As an example of the type of reply that I'm looking for, here's an example
>for (telephone) modems:
>
>   Another feature that you should look for is built-in error correction
>   and data compression.  v.42bis compression can get (theoretically) up
>   to a 4:1 compression ratio making a 14400 bps modem effectively a
>   57600 bps modem.  However, the peak expected compression is about 2:1.
>
>As a packet protocol, EC (error correction) is inherent in the protocol,
>correct?  Would a TNC with builtin DC (data compression) (effectively) be
>ruled out because of the FCC restriction on "clear text" transmission?  Or,
>would it be ruled out because of the need of the remote modem to maintain
>an updated compression table which isn't feasible?


I am going to purchase a Packet Data Engine this Dayton. If anyone is
interested, I would like to develop some new software for it.
Preferrably something to do data compression at high speed. Any takers?

73,
stuart b. tener, n3gwg
tener@cs.widener.edu
(215)-338-6005

------------------------------

Date: Mon, 15 Feb 93 03:49:21 GMT
From: mnemosyne.cs.du.edu!nyx!jmaynard@uunet.uu.net
Subject: Palmtops and packet?
To: packet-radio@ucsd.edu

In article <1993Feb13.205732.16290@magnus.acs.ohio-state.edu> jmilhoan@magnus.acs.ohio-state.edu (JT) writes:
>I think an hp95-lx or some other palmtop which is more like a true-PC
>would be much nicer than a Wizard because of all the ham software
>available for the DOS platform.  The hp95-lx has a serial port, but I
>don't think it has a slot... at least not the "type 2" slots which the
>modems are being made for.  Type 1 is just for memory cards (I think!
>I'm not positive on the slot-thang).

The HP95LX runs a slightly modified version of KA9Q very nicely, thank
you. One caution, though: the serial transmitter eats batteries.

I don't think a PCMCIA TNC would sell well; there aren't any palmtops I'm
aware of yet that have Type II slots, and while there are Type I modems,
there's quite a bit more market for those, and they're very machine
specific (because they have to run special software to talk to the modem
as a memory-mapped device, since all Type I supports is memory).

(BTW, does anyone know if the mods I made for the 95's serial port got
folded into the stock KA9Q [or variant thereof] software? They should work
OK on normal machines... If not, I'll pick up a current copy of one of the
packages' source code, or get with any or all authors and describe the
necessary mods.)
--
Jay Maynard, EMT-P, K5ZC, PP-ASEL | Never ascribe to malice that which can
jmaynard@oac.hsc.uth.tmc.edu      | adequately be explained by stupidity.
 "Support your local medical examiner - die strangely." -- Blake Bowers

------------------------------

Date: Sat, 13 Feb 1993 17:24:51 GMT
From: sdd.hp.com!cs.utexas.edu!torn!watserv2.uwaterloo.ca!watserv1!ritchie.uwaterloo.ca!owpurbo@network.UCSD.EDU
Subject: Posting to NOS NNTP
To: packet-radio@ucsd.edu

In article <1993Feb11.180355.16233@csusac.csus.edu> chuckb@babbage.csus.edu (Chuck Bland) writes:
>OK, so I can GET news from an nntp news server with NOS. How to I
>POST news from one nos node to my nntp server, rf or otherwise ?
>
>Chuck Bland
>chuckb@babbage.ecs.csus.edu
>n6dbt


Chuck:
If your NOS is compiled with NNTP server built-in
you should be able to do it easily by turn on
the:
	nntp ihave 1

In fact a couple of us have been doing NNTP forwarding
between NOS NNTP servers in AMPRNet for a couple of months now.

Unfortunately, the off-the-shelf NOS.EXE (from ucsd.edu)
doesn't come with NNTP server built-in - 
Some have NNTP client built-in but not NNTP server
so you have to compile it yourself.

73 Onno YC1DAV/VE3 -sk-
        yc1dav@ve3.yc1dav.ampr.org [44.135.84.22]

------------------------------

Date: 14 Feb 93 12:59:06 GMT
From: news-mail-gateway@ucsd.edu
Subject: Posting to NOS NNTP
To: packet-radio@ucsd.edu

I have written a utility valled PNEWS which does exactly this: Post
articles to specified NNTP groups. It is based partially on code
developed by EI9GL (Paul Healy) for BMH02 and by Bdale Garbee for
BM.EXE. You should be able to find it on UCSD.EDU.
There is also a new release with some bug fixes, but I cannot ftp
to ucsd.edu anymore. If someone would like to upload it there,
I can send him a floppy disk by mail.

73 Costas SV1XV (ex G7AHN)


------------------------------------------------------------------
|   Dr. K. Krallis  SV1XV *   Epsilon Software S.A.
|  ------
|  Internet:  kkrallis@leon.nrcps.ariadne-t.gr
|  Packet radio: SV1XV @ SV1IW.ATH.GRC.EU
|  AMPRnet:   sv1xv@sv1xv.ampr.org         [44.154.1.11]
|  Snail Mail:  P.O.BOX 3066, GR-10210 Athens, GREECE
------------------------------------------------------------------

------------------------------

Date: Mon, 15 Feb 93 02:04:42 MST
From: cs.ubc.ca!unixg.ubc.ca!kakwa.ucs.ualberta.ca!ersys!ve6mgs!rec-radio-info@beaver.cs.washington.edu
Subject: Welcome to rec.radio.info!
To: packet-radio@ucsd.edu

Archive-name: radio/rec-radio-info/welcome
Last-modified: $Date: 1993/02/14 09:17 $
Version: $Revision: 1.02 $

*** Welcome to rec.radio.info! ***

Welcome to rec.radio.info, a group that aims to provide a noise-free source
of information and news for the entire rec.radio hierarchy.

Two introductory articles about rec.radio.info are posted to the group and
to news.answers every two weeks. You are now reading the first article, which
explains what rec.radio.info is, and answers some Frequently Asked Questions. 
The second article is titled "Submission Guidelines", and you only need to 
read it if you want to submit an article to rec.radio.info.

 -- What is the purpose of rec.radio.info?

The purpose or charter of rec.radio.info is to provide the Usenet community with
a resource for information, news, and facts about any and all things radio.

All the other rec.radio groups are intended for discussions and general chit
chat about radio.  Rec.radio.info will contain informational, factual articles
only. Follow-ups are redirected to an appropriate other group, and further
discussion (if any) will not take place in rec.radio.info.

In order to ensure that rec.radio.info contains only appropriate articles, it
was decided to create the group as a moderated newsgroup.

 -- Why are messages almost always cross posted to rec.radio.info?

It provides a "tag" for each article to be assembled into a filtered
presentation in rec.radio.info (even with cross-posting, only one message, with
a unique Message-ID, is propogated across the net).  This tag also facilitates
a pre-existing method of dropping or cancelling the articles locally within the
discussion groups if you don't want to see them.  This accommodates individuals
who want to separate the bulletins from the discussions, discussions from the
bulletins, as well as those who are adamant about not reading another
newsgroup and wanted to see everything all in one basket.  

With the total size of Usenet (in number of newsgroups and total traffic)
doubling every year or so, this is no insignificant contribution to reducing
information noise and chaos.  Making the discussion groups a catch-all, and
making extra newsgroups filters on that catch-all, is also the most realistic
way to implement such a scheme (It's not intuitively obvious what the charter,
contents, and general appropriate topics for each and every newsgroup are.
Seeing FAQ's and charter/intro postings in the home newsgroup is beneficial
for new readers).

By cross-posting one only is adding a few tens of bytes to each bulletin (to
specify the extra group on the Newsgroups line), but are adding the capability
for very powerful filtering features available on most news servers and
readers.  Your local news guru could probably explain these features in more
detail.

 -- What is a 'follow-up', and what does 'moderated' mean?

If you are new to Usenet and are not familiar with the terminology, you might
want to read the general introductory articles found in the newsgroup
news.announce.newusers. Doing so will make your life on the net much easier,
and will probably save you from making silly beginner's mistakes.

If you think that at this moment you are reading an echo, a conference, or
a bulletin board, I'd also strongly suggest a trip over to
news.announce.newusers.

For the rest of this article, I will assume you have a basic knowledge of
Usenet terminology and mechanics.

 -- OK, so now I know what 'moderated' means. Tell me more.

Rec.radio.info is a moderated newsgroup, which means that all articles
submitted to the group will have to be approved by the moderator first.

The current moderator of the group is Mark Salyzyn.  Submissions to
rec.radio.info can be posted, or e-mailed to:

		rec-radio-info@ve6mgs.ampr.ab.ca

Comments, criticisms, suggestions or questions about the group can be e-mailed
to:
		rec-radio-request@ve6mgs.ampr.ab.ca

But before you do so, please be sure to check out the "Submission Guidelines"
article.

The influence of the moderator should be minimal and of an administrative
nature, consisting chiefly of weeding out obviously inappropriate articles,
while making sure correct headers etc. are used for the appropriate ones.

 -- What type of material is considered inappropriate?

There are three broad categories of articles which will be rejected by the
moderator:

1) Requests for information: rec.radio.info is strictly a one-way street.  I
   receive information in my mailbox; I then post it to rec.radio.info.
   Requests for specific information belong in the normal discussion newsgroups.
   If your request gets answered, you might consider passing the answer on to
   rec.radio.info, though. Especially if you can edit it into a informational,
   rather than a discussion, format.

2) Obvious discussion articles, or articles that appear unsubstantiated.

3) Commercial stuff: a relatively unbiased test of a radio product would be
   accepted, but any hint of for-profit might be reason for rejection. For three
   reasons: This is not the purpose of the list, for-profit is a controversial
   topic, and this list may be passed onto Amateur Packet Radio (where
   for-profit is prohibited except under certain provisos).

   rec.radio.swap may be more deserving of the posting in any matter.

   Similarly, copyrighted material generally cannot be used.  If it's TRULY
   worthwhile to the net, I would recommend obtaining permission from the
   copyright holder.  Please note the source, and if permission was given.  I
   reserve the right to make the final decision concerning appropriateness in
   all situations.  In most cases, a brief summary of, or pointer to, the
   copyrighted information may be all I can allow.

 -- I do not have access to news, how can I get the information posted to
    rec.radio.info?

brian@UCSD.EDU (Brian Kantor) has kindly supplied a mail list server for
rec.radio.info. Non of the articles will be digested, due to their size, so
you will receive individual mailings for every article posted to the group.

Mail sent to radio-info@ucsd.edu will be forwarded to the moderator and
thus is an alias to rec-radio-info@ve6mgs.ampr.ab.ca

To subscribe and unsubscribe via the listserver; the format for that is

	sub address radio-info
	unsub address radio-info

where 'address' is your full mailing address. Send this request to

	listserv@ucsd.edu
	
Note that the server will automatically delete any address that bounces mail.
If you leave the address portion blank, it will try to deduce your address
from the mail headers. This may not work if you are on bitnet, milnet or
some other non-Unix host, so it is recommended to put your return address
in any case. For example:

	sub mymailbox@myhost.mydomain.mil radio-info
or
	sub MEMEME01@DMBHST.bitnet radio-info

or something like that.

 -- Will the material appearing in rec.radio.info be archived somewhere?

Yes. Still firming up details at the moment but here is a preliminary list:
	- unbc.edu as maintained by Lyndon Nerenberg <lyndon@unbc.edu>
	- nic.funet.fi maintained by Risto Kotalampi <rko@cs.tut.fi>
		saved to /pub/dx/text/rec.radio.info currently stored as
		numbered files.

Effectively this means that anything you post to rec.radio.info will be
permanently stored, so your work will not be lost.

 -- I have a regular posting with timely information, is there a way to
    speed up it's delivery, or automate for more convenience?

Yes, there is! It may take a bit of chatter with the moderator, but we are
willing to take responsible people and provide them the means of posting the
articles directly from their site. We will try everything we can as we fully
realize that DX (distant signal) and astronomical data can be somewhat
transitory. We are also willing to allow regular posters of information the
same courtesy, even if the information is not as timely.

We refer to this as self-moderation, which is partly based on the model for
news.answer. This requires co-operation and good will to be beneficial to
the community in the rec.radio hierarchy.

I suggest reading the posting guidelines for more information. I am open to
suggestions.

I thank the following individuals for their input into this article:
	The rec.music.info moderator ...
	The rec.radio.broadcasting moderator Bill Pfeiffer wdp@gagme.chi.il.us
	Paul W. Schleck, KD3FU pschleck@unomaha.edu
	Ian Kluft, KD6EUI ikluft@uts.amdahl.com

-- 
Mark Salyzyn -- Moderator rec.radio.info
Submissions to: rec-radio-info@ve6mgs.ampr.ab.ca
Administrivia to: rec-radio-request@ve6mgs.ampr.ab.ca
* Requests for information do *not* belong in rec.radio.info *

------------------------------

Date: Fri, 12 Feb 1993 15:50:56 GMT
From: mvb.saic.com!unogate!news.service.uci.edu!usc!zaphod.mps.ohio-state.edu!pacific.mps.ohio-state.edu!cis.ohio-state.edu!udecc.engr.udayton.edu!udcps3!dmapub!apontej@network.UCSD.EDU
Subject: Yaesu FT-990 & PK232MBX Users?
To: packet-radio@ucsd.edu

I am interested in talking to users of the above equipment that use it on the
20m band. Also anyone else who has used it for or on remote control operator
which as I understand the FCC rules is legit, since only a few have the FCC STA
for automatic operation. My desire is to interface the PC to change frequencies
and change other parameters to stay locked in to or connected to others in the
main 20 m frequencies. At present I am reading the documenation manuals for the
TNC and the Transceiver and experimenting manually, I believe the TNC has a
technical manual which I should get..Does anyone know if AEA is on packet or
what would someone packet address will be at AEA? Maybe the internet or packet 
address of the author of the software which come with the PK232MBX (Ed L...) do
no remember his name. If anyone has done this allready on HF please contact me/

I plan to use some of the PK monitor command to determine if I am on frequency
and change it accordingly, along with other tranceiver or TNC coomads. Like I said
I am still experimenting manually with limited sucess maybe due to unfamiliarity with the software package or equipment.

The call sign being used is the club station W8BI. 

I acan be reached via internet email or packet at either

N8WPB@W8BI.#day.oh.usa.na or n8wpb@n8acv.#day.oh.usa.na


N8@W 

------------------------------

End of Packet-Radio Digest V93 #41
******************************
